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Defence  Research  and  Development  Canada  -  Valcartier  has  sponsored  the 
development  a  Conceptual  Operational  Model  of  the  strategic  planning  process  within  the 
Canadian  Forces  Joint  Staff.  This  model  is  intended  to  convey  an  understanding  of  the 
processes  within  the  headquarters  for  planning  and  monitoring  international  missions.  As 
such,  it  captures  the  command  and  control  processes  at  the  strategic  level  of  the 
Department  of  National  Defence. 

The  objective  was  to  construct  an  IDEF  process  model.  An  IDEF  model  is, 
however,  a  rather  abstract  representation  and  is  not  easily  interpreted  by  itself.  Therefore, 
the  process  adopted  was  to  apply  the  information  from  surveying  the  Joint  Staff  in 
constructing  three  different  views  that  contribute  to  the  construction  of  an  IDEF  model. 
The  first  step  was  a  simple  context  model  that  shows  a  single  process  (Plan  development) 
and  the  primary  interfaces  with  that  process.  The  context  diagram  was  supplemented  with 
an  activity  diagram  that  breaks  the  process  down  into  discrete  activities  and  allocates 
those  activities  to  the  organizational  elements.  The  third  view  constructed  was  a 
hierarchical  view  of  the  activities  that  provides  a  structured  and  more  detailed  breakdown 
of  the  activities.  The  three  views  of  the  planning  process  provide  most  of  the  information, 
in  an  easily  understood  form,  that  can  be  applied  to  the  construction  of  an  IDEF  model. 

The  model  describes  the  process  activities,  objects  and  attributes  necessary  to 
enable  an  evaluation  of  the  headquarters  process.  The  model  enables  the  identification  of 
target  organizational  cells  for  which  new  tools  may  be  offered  to  improve  the 
effectiveness  of  specific  activities,  such  as  mission  planning,  or  to  improve  the  quality  of 
the  products  of  those  activities.  The  Canadian  Forces  organization  is  large,  includes  many 
resources  and  carries  out  a  wide  range  of  activities  in  support  of  Canadian  national 
interests.  The  Conceptual  Operational  Model  is  the  first  step  in  the  development  of  new 
support  tools  specifically  in  the  domain  of  situation  awareness  and  strategic  planning. 
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Introduction:  Managing  Complexity 

With  the  emergence  of  network  centric  warfare  has  come  increasing  complexity 
in  managing  command  systems  to  cope  with  the  operational  requirements  of  fielding 
task-tailored  combat-ready  forces  in  a  global  environment  in  which  each  operation 
appears  to  be  a  custom-tailored  affair.  Fielding  adaptive  collaborative  command  systems 
at  a  moments  notice  to  suit  the  coalition-specific  organizational  environment  is  a 
continuing  and  daunting  challenge  as  we  charge  into  the  21st  century.  The  demand  for 
new  operational  capabilities  is  accelerating  at  roughly  the  same  rate  as  technology  is 
developing.  The  rapid  pace  of  change  generates  new  ideas  that  can  be  quite  distracting 
and  very  costly  if  they  don’t  pan  out.  Change,  while  it  tempts  us  with  the  promise  of 
newer,  faster  methods  of  doing  things,  can  be  disruptive  and  counterproductive  unless  the 
changes  are  implemented  in  a  coordinated  and  integrated  fashion.  New  capabilities  need 
to  interoperate  with  existing  capabilities  and  across  multiple  organizational  boundaries 
affecting  many  stakeholders.  Implementing  multiple  new  capabilities  in  parallel  requires 
great  discipline,  collaboration  and  cooperation  among  stakeholders.  Unfortunately, 
discipline,  collaboration  and  cooperation  among  stakeholders  often  translates  into 
bureaucratic  procedures  and  costly  delays  that  ensure  new  capabilities  are  obsolete  by  the 
time  they  are  deployed.  The  Canadian  Forces,  as  do  all  others,  have  an  urgent  need  to  be 
able  to  roll  out  incremental  operational  capabilities  quickly.  The  work  reported  herein, 
describes  a  modeling  approach  to  contribute  toward  that  goal. 

The  greatest  risk  in  managing  evolutionary  systems  is  establishing  a  common 
understanding  between  stakeholders.  Failure  to  understand  concepts,  objectives, 
priorities  and  expected  outcomes  is  the  largest  obstacle  in  the  path  between  concept  and 
deployment.  The  magnitude  of  the  risk  is  directly  related  to  the  number  of  stakeholders 
and  the  number  of  interfaces  involved. 

An  operational  model  is  an  effective  and  essential  element  of  developing  a 
common  understanding  between  operators,  architects,  developers  and  project  managers. 
Having  said  that,  the  next  issue  is  deciding  which  modeling  technique  to  apply.  Two  of 
the  leading  contenders  are: 

1.  IDEF  Business  Process  Model,  and; 

2.  Unified  Modeling  Language  (UML). 

IDEF  is  an  acronym  for  I-CAM  Definition  Methods.  I-CAM  is  the  acronym  for 
Integrated  Computer-Aided  Manufacturing,  a  U.S.  Air  Force  project  to  develop  methods 
for  improving  manufacturing  productivity  through  the  use  of  computer  technology.1 

IDEF,  rooted  in  the  manufacturing  environment,  has  matured  since  its  emergence 
as  a  standard  in  the  1980’s,  progressing  to  a  much  more  sophisticated  modeling  language, 
capable  of  high  fidelity  representation  of  interactive  processes.  However,  the  software 
industry,  following  Object-Oriented  methods,  has  largely  adopted  UML  for  capturing 
requirements  and  developing  applications.  The  dominant  modeling  language  for 
developers  today  is  UML2.  UML  has  become  the  standard  for  the  development 
community  today  because  it  is  derived  from  and  is  consistent  with  object-oriented 
development  methodologies.  Most  IT  and  geospatial  standards  today  have  adopted  UML 
as  the  modeling  language  for  use  in  expressing  standards. 
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UML  tools  are  also  well  integrated  with  the  tools  of  the  development  environment, 
facilitating  the  transition  from  requirements  modeling  to  the  code  development  and 
ensuring  traceability  between  requirements  and  code.  While  UML  is  well  suited  to  the 
development  environment,  its  abstract  nature  and  complex  graphical  notation  make  it 
difficult  for  operational  managers  to  grasp.  The  jargon  of  UML  is  the  jargon  of 
developers.  At  the  business  process  level  operational  managers  tend  to  find  the  IDEF 
convention  easier  and  quicker  to  grasp.  The  jargon  of  IDEF  is  still  rooted  in  the 
operational  environment. 

The  IDEF  business  process  technique  was  chosen  to  model  at  the  enterprise  level 
with  the  expectation  that  UML  would  be  more  effective  at  the  application  development 
level  where  there  is  a  great  deal  of  interaction  between  the  individual  operator  and  the 
system  user  interfaces.  Before  delving  into  the  highly  detailed  and  interactive  application 
level  it  is  necessary  to  establish  an  enterprise  level  model  that  portrays  principal  business 
processes  and  is  based  on  guiding  documents  such  as: 

1.  Strategic  departmental  documents; 

2.  Operational  doctrine,  and; 

3.  Standard  Operating  Procedures. 

If  the  primary  objective  of  an  operational  model  is  to  establish  a  common 
understanding  between  stakeholders,  then  three  conditions  are  essential: 

1.  The  model  should  present  information  at  an  appropriate  level.  Too  much  detail 
will  be  distracting  and  divisive. 

2.  The  model  must  relate  closely  to  the  guidance  documents  identified  above.  It  is 
essential  that  the  key  guidance  documents  be  directly  accessible  from  the 
graphical  elements  of  the  model.  Guidance  information  at  hand  is  necessary  to 
develop  understanding  and  to  identify  and  clarify  issues  when  changes  to  doctrine 
and  SOPs  are  being  planned. 

3.  The  language  used  in  the  model  must  be  in  the  language  of  the  operators,  rather 
than  the  language  of  architects  and  developers. 


The  IDEF  business  process  modeling  technique  has  proven  to  be  an  effective 
method  for  describing  operational  processes.  The  simple  diagramming  language  is 


quickly  grasped  and  understood.  It  conveys  a  level  of  information  appropriate  for 
expressing  business  processes.  The  original  function  modeling  method,  IDEFO,  has 
spawned  an  integrated  set  of  methods  for  comprehensive  systems  engineering  and 
development: 

IDEFO 

Function  Modeling  method 

IDEF  lx 

Data  Modeling  method 

IDEF3 

Process  Flow  and  Object  State  Description  Capture  Method 

IDEF4 

Object-Oriented  Design  Method 

IDEF5 

Ontology  Description  Capture  Method 
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IDEF3  is  an  appropriate  method  for  use  in  the  COP21  operational  model  because 
it  captures  the  behavioral  aspects  of  systems  rather  than  simple  sequential  functions.3 

The  diagram  in  Figure  1  below  illustrates  the  basic  convention  of  the  IDEF3 
Model,  with  the  processes  involved  in  a  paint  operation,  which  includes  a  quality  check 
and  re-work,  if  necessary.2 


Figure  1:  IDEF  Model  Convention 


The  simple  elements  of  Inputs,  Outputs,  Controls  and  Supporting  Mechanisms 
enable  most  of  the  needs  of  the  business  process  to  be  captured.  Associated  with  each 
element  (Arrow  entities  and  Box  activities)  is  information  that  describes  the  entity  or 
activity. 

The  Modeling  Process 

The  COP21  Conceptual  Operational  Architecture  project  modeled  the  processes 
of  the  Joint  Staff  at  Canada’s  National  Defence  Headquarters.  The  focus  was  on 
processes  related  to  operations  planning  and  acquiring  situation  awareness.  For  the  sake 
of  brevity  the  following  paragraphs  describe  the  approach  using  a  few  examples  of 
products  resulting  from  the  work. 

It  is  difficult  to  construct  a  model  in  a  single  step.  There  are  too  many  entities, 
interfaces  and  relationships  to  understand  and  cope  with  at  a  single  stroke.  A  set  of 
simple,  differing  views  often  produces  the  understanding  required  to  construct  a  more 
effective  model.  The  objective  is  to  construct  an  IDEF  process  model,  but  starting  with 
an  IDEF  model  is  probably  not  the  most  constructive  way  to  achieve  that  result.  The 
process  adopted  in  this  case  is  to  apply  the  acquired  information  in  constructing  three 
different  views  that  contribute  to  the  construction  of  the  IDEF  model.  The  first  step  is  a 
simple  context  model  that  shows  a  single  process  (Plan  development)  and  the  primary 
interfaces  with  that  process. 
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The  context  diagram  is  supplemented  with  an  activity  diagram  that  breaks  the 
process  down  into  discrete  activities  and  allocates  those  activities  to  the  organizational 
elements,  or  individual  actors.  The  sequence  of  activities  shown  in  the  diagram  describes 
the  timing  of  the  activities. 

The  third  view  constructed  is  a  hierarchical  view  of  the  activities  that  provides  a 
structured  and  more  detailed  breakdown  of  the  activities. 

With  the  three  views  of  the  planning  process,  we  have  most  of  the  information,  in 
an  easily  understood  form  that  can  be  applied  to  the  construction  of  an  IDEF  model. 


Context  Diagram  -  Strategic  Planning  and  Situation  Awareness 

The  context  diagram  shown  below  [Figure  2]  provides  a  simple  perspective  of  the 
planning  function,  yet  illustrates  important  concepts  and  relationships. 


Figure  2:  Context  Diagram  Planning 


For  instance,  the  trigger  event  is  the  initiating  directive  and  the  outputs  are 
Courses  of  Action  (COAs)  and  Contingency  Operations  Plans  (COPs).  There  are  other 
intermediate  products,  but  these  are  the  primary  products  of  the  planning  process.  The 
diagram  also  illustrates  that  there  is  a  wide  variety  of  information  that  supports  the 
planning  process,  some  of  which  is  generated  as  a  result  of  the  planning  activities. 
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The  third  fundamental  concept  illustrated  by  the  context  diagram  is  the  key 
participants,  or  actors,  in  the  organization  that  contribute  to  or  perform  planning 
activities. 

With  regard  to  supporting  information,  the  diagram  illustrates  that  it  is  the 
supporting  information  that  provides  situation  awareness  when  the  information  is 
accessible  by  the  planning  personnel.  Furthermore,  situation  awareness  includes  not  only 
intelligence  about  the  adversary  (red  forces),  but  also  information  about  the  environment, 
as  well  as  information  about  CF  and  coalition  assets. 

This  context  diagram  also  enables  the  cataloging  of  actors,  activities,  and  of 
entities  and  attributes  associated  with  those  entities. 

It  is  also  worthwhile  to  point  out  that  the  planning  process  is  a  continuous  process 
that  spans  the  operation  from  inception  to  completion  and  redeployment  following  the 
operation.  At  the  strategic  level,  the  actors,  activities,  tools  and  processes  are  either  the 
same  or  a  subset  of  the  total  activities  for  each  of  the  five  phases  of  the  operation. 
Therefore,  getting  the  process  of  planning  and  working  effectively  with  situation 
awareness  provides  effective  results  through  the  life  of  the  operation. 


Activity  Diagram  -  JSAT  Peace  Support  Planning  Scenario 

The  diagram  shown  below  is  a  high-level  activity  diagram  that  illustrates  the  Joint 
Staff  Action  Team  (JSAT)  process  applied  to  the  typical  United  Nations  (UN) 
peacekeeping  support  scenario.  The  activity  diagram  illustrates  the  sequence  of  activities 
and  the  roles  of  each  of  the  organizational  elements  in  the  process.  Each  actor  is  assigned 
to  one  of  the  “swimlanes”.  The  timing  of  the  sequence  is  indicated  in  the  vertical 
dimension. 
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Figure  3:  Activity  Diagram  Planning  for  Peacekeeping  Support 

The  period  of  time  from  the  request  from  the  UN  through  COA  development  to 
the  Decision  Brief  may  be  a  few  days  to  several  weeks.  The  typical  time  from  approval 
and  issue  of  the  Warning  Order  to  the  issue  of  the  Operations  Order  (Op  O)  may  two  to 
four  months  because  of  the  effort  required  to  do  the  detailed  operational  planning.  The 
issue  of  Warning  Orders  is  consistent  with  the  DCDS  appointing  a  Task  Force 
Commander  who  assumes  responsibility  for  the  development  of  the  operational  plans. 
The  JSAT  continues  to  support  the  TFC  through  the  planning  process.  Once  the  Op  O 
has  been  issued,  COS  J3  staff  officers  support  the  mission  throughout  the  operation. 

The  activity  diagram  shown  in  Figure  3  is  a  UML-style  diagram  used  to  capture 
operational  concepts.  Using  the  UML  activity  diagram  in  conjunction  with  the  IDEF 
process  model  adds  useful  information  to  the  IDEF  model  while  building  a  bridge 
between  IDEF  and  UML  for  the  developer  community.  The  activity  diagram  conveys  an 
understanding  of  related  activities  that  complements  the  hierarchical  decomposition  style 
of  the  IDEF  model.  Taken  together,  the  observer  may  acquire  a  better  understanding  of 
the  operational  concepts  than  by  viewing  just  one  or  the  other. 
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Hierarchy  of  Activities 

All  of  the  above  information  leads  to  the  ability  to  construct  a  list  of  activities  in  a 
hierarchical  fashion  that  allows  more  detailed  activities  to  be  added  incrementally  as 
knowledge  of  the  model  grows.  Figure  4  illustrates  a  hierarchy  of  activities  for  the 
strategic  planning  process,  which  includes  the  participation  of  the  cells  of  the  J  Staff. 


1 .0  CDS  Initiating  Directive 

1 .1  Mission  Analysis 

1.2  DCDS  Planning  Guidance 

1 .3  Int  Threat  Assessment 


2.  Develop  COA’s 

2.1  Guidance  Review 

2.2  Dev  Initial  COA’s 

2.3  Evaluate  COA’s 

2.4  Cmdr’s  Review 

2.5  Strategic  Recce 

2.5  Refine  Staff  Estimates 

2.6  Prepare  Decision  Brief 

3.0  DCDS  COA  Decision 


4.0  Develop  Plans/Orders 

4.1  Refine  Int  Threat  Assessment 

4.2  Prepare  Plans 

4.3  Review  Plans 

4.5  CDS  Approve  COO 

5.0  Execute 

5.1  GOC  Approval 

5.2  Issue  Warning  Order 


Figure  4:  Hierarchy  of  Planning  Activities 

The  simple  hierarchy  view  provides  a  guide  for  decomposing  the  IDEF  processes 
into  subordinate  activities.  It  serves  as  a  checklist  for  completeness. 

The  combination  of  the  three  views  (Context,  Activity,  and  Hierarchy)  provides 
an  effective  method  for  managing  and  supporting  the  development  of  the  IDEF  model. 
The  three  views  also  provide  complementary  information  that  is  easily  included  in  the 
process  description  within  the  IDEF  model. 


IDEF  Process  Model 

Modeling  in  the  IDEF  convention  is  a  decomposition  process  in  which  the 
principal  mission-specific  process  is  decomposed  into  lower  level  sub-processes.  The 
figure  below  [Figure  5]  is  the  AO  Enterprise  activity  for  the  Canadian  Forces.  The 
mission  of  the  CF  is  to  defend  Canada  and  Canadian  interests.  The  activities  of  the  CF 
are  constrained  by  legislative  regulations  and  policies,  the  global  environment  and  by  the 
policy  that  requires  the  CF  to  operate  internationally  with  allied  governments.  The  inputs 
to  the  CF  enterprise  consists  of  government  strategic  direction,  specific  operational 
taskings,  and  funding  for  operations  and  capital  expenditures.  The  CF  also  receives 
information  from  non-CF  sources  including  Canadian  and  coalition  intelligence, 
surveillance  and  reconnaissance  sources.  The  products,  or  outputs  of  the  CF  enterprise 
include  completed  missions,  business  plans,  management  reports  and  responses  to 
information  requests  as  well  as  support  for  other  government  departments  and  programs. 
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The  CF  also  provides  support  to  allied  and  coalition  operations.  In  the  conduct  of  those 
operations,  the  CF  may  utilize  supporting  resources  from  coalition  force  capabilities. 


GOC  Legislation 
Regulations  & 
Policies 
GOC  Approval 


Global  Environment 


Allied  Interoperability 


GOC  Direction 


GOC  Tasking 

u 

GOC  Fundina  l_ 

- ► 

Cdn  ISR  Sources  ( 

- ► 

Coalition  ISR  Products _ J 

Defend  Canada | 
and  Canadian 
Interests 

AO  I 


AO.  1 


Completed  Missions  , 
DND  Business  Plans  ■ 


DND  Management 


Reports 


~T  Response  to  Info  Requests 
1  Support  for  GOC  Prooramg 


Support  Coalition  Op^ 


Coalition  Force 
Capabilities 


Figure  5:  Top  Level  (AO)  Enterprise  Activity  for  the  CF 

The  diagram  expresses  the  enterprise  mission  of  the  CF  quite  well.  However,  the 
decomposition  of  the  subordinate  activities  requires  some  careful  consideration. 

There  is  more  than  one  enterprise  view  of  DND.  One  view  is  expressed  in  the  CF 
Force  Employment  Manual  (FEM)4.  The  Forward  section  of  the  FEM  introduces  a 
model  that  defines  four  core  processes.  A  more  recent  model,  CF  Ops  Enterprise  Model5, 
defines  the  core  processes  in  a  significantly  different  manner.  It  is  worthwhile  to 
examine  the  two  models  to  ascertain  the  different  approaches. 


The  CF  FEM  View 

The  CF  FEM  view  is  described  in  the  forward  of  the  FEM,  and  in  more  detail  in 
Chapter  7  of  the  FEM.  This  four  core  process  (4CP)  model  was  developed  in  1990’s  by 
the  Management  Command  and  Control  Re-engineering  Team  (MCCRT),  an  internal 
review  process  sponsored  by  the  Department  of  National  Defence.  The  node  tree 
diagram  of  the  IDEF  model  is  shown  below. 
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Figure  6:  The  MCCRT  Four  Core  Process  Model 

The  definition  of  activities  allocated  to  each  of  the  four  core  processes  yields 
insight  into  the  rationale  for  the  decomposition  of  the  mission  into  the  four  processes. 
The  rationale  expresses  a  high-level  sequential  process  view  of  the  organization  from 
strategy  through  preparation  to  execution. 


The  CF  Ops  Enterprise  View 


The  CF  Ops  Enterprise  model  constructed  more  recently,  is  based  on  a  three  core 
process  view  of  the  same  lower  level  processes  as  in  the  CF  FEM  view: 


Figure  7:  Three  Core  Process  Model 
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The  allocation  of  principal  activities  to  the  core  processes  expresses  an  enterprise 
view  that  recognizes  that  the  CF  organizes  and  conducts  operations  on  strategic, 
operational,  and  tacticcd  levels.  Furthermore,  Enterprise  direction  is  more  than  strategic 
direction  and  is  not  well  expressed  in  the  four  core  process  model.  Another  motive  is  the 
implementation  of  the  OODA  loop  at  each  level  of  the  organization  and  operation. 

OODA  is  the  Observe,  Orient,  Decide  and  Act  repetitive  sequence  that  indicates  that  the 
planning  and  execution  of  activities  occurs  all  across  the  organization  and  occurs 
continuously  within  an  operation  through  each  of  the  five  phases  of  the  operation. 

Inspection  of  the  more  detailed  activities  in  the  4CP  model  shows  that  they  can  be 
mapped  into  the  activities  of  the  3CP  model.  For  instance,  in  the  3CP  model,  the  process 
“Provide  Military  Forces”  includes  the  major  elements  of  Force  Generation  and  Force 
Employment  in  the  4CP  model.  In  the  3CP  model  the  activities  related  to  capability 
planning  have  been  allocated  to  the  Enterprise  Direction  process.  The  important 
strategic,  operational  and  tactical  levels  of  operation  are  expressed  at  the  highest  level  of 
the  decomposition. 

It  is  the  view  of  the  writers  that  the  decomposition  of  the  3CP  model  better 
reflects  the  most  important  organizational  and  operational  characteristics  of  DND  than 
does  the  sequential  flow  rationale  of  the  4CP  model. 

However,  the  3CP  model,  at  the  outset  of  this  project  was  not  populated,  beyond 
the  identification  of  the  process  structure  and  interconnecting  arrows.  The  major  portion 
of  the  work  of  the  project  has  been  populating  and  adapting  the  3CP  model  from  the 
information  contained  in  the  CF  doctrine  manuals  and  SOP’s,  supported  by  the 
interviews  with  the  Joint  Staff  at  NDHQ.  The  populated  enterprise  model  can  be  used  for 
concept  development  and  experimentation  leading  to  new  operational  capabilities  for 
strategic  planning  and  situation  awareness. 

The  preceding  discussion  underscores  the  importance  of  understanding  the 
enterprise  before  beginning  the  modeling  process.  The  first  step  in  decomposition  will 
have  great  impact  on  the  way  in  which  the  model  is  interpreted.  It  also  underscores  the 
significance  of  explaining  to  the  stakeholders  the  rationale  for  the  chosen  approach  to 
decomposition. 


Decomposition  of  Level  1  Activities 

To  make  the  preceding  discussion  meaningful  it  is  useful  to  present  the  level  one 
activities  for  each  of  the  three  core  processes.  The  business  process  A1  Provide 
Enterprise  Direction  is  decomposed  and  illustrated  in  Figure  8.  The  core  business 
process  A2  Provide  Military  Forces  is  decomposed  and  presented  in  Figure  9.  The  third 
core  business  process  A3  Provide  Common  Support  Services  is  decomposed  and 
presented  in  Figure  10. 
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Figure  8:  A1  Provide  Enterprise  Direction 


Figure  9:  A2  Provide  Military  Forces 


Larry  Cochran  and  Kendall  Wheaton 


12 
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Figure  10:  A3  Provide  Common  Support  Services 

The  three  Level  1  diagrams  are  indicative  of  how  quickly  the  decomposition 
process  can  become  complicated  and  why  it  is  necessary  to  give  careful  thought  to  the 
organization  and  approach  to  decomposition.  If  too  many  activities  are  allocated  to  a 
given  level  in  the  diagrams,  it  gets  messy  and  unmanageable.  There  is  a  significant 
element  of  art  involved  in  the  practice  of  decomposition.  It  is  important  for  the  modeler 
to  understand  the  needs  and  objectives  of  the  stakeholders  in  order  to  provide  a  model 
that  will  meet  their  needs. 

It  will  be  obvious  to  some  observers  that  some  details  may  be  missing  from  the 
diagrams.  Modeling  is  a  evolutionary  and  incremental  process.  Seldom  is  a  model  called 
complete.  It  is  also  important  for  models  to  be  embraced  by  the  stakeholders,  for  them  to 
participate  in  the  construction  and  validation  of  the  model.  Otherwise,  they  will  fail  to 
understand  the  model,  will  not  take  ownership  of  their  portion  of  the  model  and  will  be 
less  likely  to  make  good  use  of  it. 
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Supporting  Documentation 

Contrary  to  popular  belief,  the  reason  for  constructing  operational  models  is  not  to 
provide  employment  for  OR  scientists,  but  rather  to  enable  stakeholders  who  are  not  OR 
scientists  to  engage  the  model  in  order  to  examine,  understand  and  evaluate  new 
concepts.  A  model  that  sits  on  the  shelf  collecting  dust  is  not  effective.  A  model  created 
by  a  proprietary  tool  that  prevents  unlicensed  users  from  interactively  engaging  the  model 
is  of  limited  value.  Furthermore,  a  proprietary  tool  that  provides  only  a  limited  capability 
to  attach  supporting  documentation  to  the  graphical  elements  imposes  a  handicap  on  the 
modeler  and  the  intended  audience.  With  these  issues  in  mind,  the  expensive  proprietary 
tools  were  abandoned  in  favor  of  a  more  accessible  and  open  approach.  The  model  has 
been  implemented  in  an  HTML  environment  using  Microsoft  Visio  as  the  graphic  tool 
with  IDEF  and  UML  templates  and  a  broad  set  of  universal  graphic  symbols.  Microsoft 
Word  and  Adobe  text  editors  have  been  employed  because  virtually  all  of  the  supporting 
documents  are  either  in  Word  or  PDF  format.  Macromedia  Dreamweaver  has  been  used 
as  the  HTML  editing  environment  to  create  the  model  in  the  form  of  a  web  page.  The 
IDEF  model  as  a  web  page  application  provides  universal  access  to  all  of  the  stakeholders 
and  incorporates  a  rich  resource  library  of  supporting  documents  that  are  directly  linked 
to  each  of  the  graphical  objects  in  the  diagrams.  Each  of  the  stakeholders  can  engage  the 
model  and  contribute  to  its  evolution  from  their  own  desktop  without  acquiring  an 
expensive  single  purpose  license  for  IDEF  modeling. 

An  invaluable  tool  for  the  modeler  as  well  as  the  stakeholders  is  a  comprehensive 
index  of  terms  which  provides  a  cross  reference  for  all  the  supporting  documents  and  a 
local  search  tool.  Having  the  capability  to  locate  every  reference  to  a  specific  term  is 
necessary  for  completeness  and  for  addressing  issues  and  conflicts.  Equally  valuable  is  a 
common  glossary  that  establishes  a  valid  definition  for  important  terms.  The  web  page 
format  also  provides  a  list  and  links  to  each  of  the  reference  documents  for  direct  access, 
enabling  users  to  get  at  the  documents  directly  or  through  the  graphic  model. 

The  model  has  been  constructed  in  modular  sections  to  enable  different 
stakeholder  groups  to  edit  and  extend  a  portion  of  the  enterprise  model  specific  to  their 
interests.  For  example,  the  activities  related  to  Provide  Situation  Awareness  A2.1,  Figure 
1 1,  are  another  section  of  the  enterprise  model.  Situation  awareness  is  primarily  the 
domain  of  intelligence  and  the  NDCC.  They  are  the  actors  who  are  responsible  for  the 
SA  processes  and  recourses  and  it  is  they  who  should  take  ownership  of  the  SA  business 
process  segment  of  the  enterprise  model.  In  like  manner,  Enterprise  Direction  activities, 
Figure  12,  are  the  responsibility  of  senior  leadership  in  the  Joint  Staff.  IM  services  that 
support  human  resources  may  not  be  of  particular  interest  to  C2  types,  but  operations 
cannot  be  planned  and  executed  without  input  from  HR  and  medical  support  groups. 
Command  systems  exist  and  operate  in  the  context  of  an  enterprise,  each  element  of 
which  has  an  important  role  to  play  in  the  mission  of  the  enterprise.  The  segmentation  of 
the  enterprise  model  facilitates  stakeholder  participation  with  the  expectation  that 
stakeholders  will  participate,  contribute  and  take  ownership  of  their  respective  segments 
of  the  model.  Such  models  are  alive  and  active,  not  sitting  on  the  shelf. 
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Figure  11:  A2.1  Provide  Situation  Awareness 


Global 


Figure  12:  Al.l  Provide  Strategic  Direction  to  Operations 
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Finally,  the  web  page  model  environment  includes  pages  for  issues  and  concepts 
to  be  expressed  outside  the  model.  These  pages  support  working  groups  of  stakeholders 
to  enable  them  to  express  views  in  such  a  way  that  all  stakeholders  can  be  aware. 

Operational  Architecture 

The  discussion  to  this  point  has  been  about  the  construction  of  an  enterprise 
operational  model.  The  operational  model,  however,  does  not  directly  express  an 
operational  architecture.  Architecture  is  about  patterns.  Just  as  a  building  design  is  based 
on  structural  patterns  to  achieve  strength  and  flexibility  of  use,  operational  architectures 
should  allow  organizations  to  establish  operational  patterns  across  the  breadth  and  depth 
of  an  organization.  The  OODA  loop  is  a  pattern  that  is  common  to  most  military 
organizations.  The  value  of  patterns  in  an  organization  is  achieved  in  the  ability  to  move 
people  from  one  position  to  another  with  minimal  time  and  effort  required  to  adapt  to  the 
new  responsibilities  or  new  environment.  Consistent  operational  patterns  are  essential  to 
developing  joint  force  capabilities.  Similarly,  operational  interoperability  between 
members  of  a  coalition  force  requires  consistent  operational  patterns  in  each  organization 
to  develop  unity  of  force  and  to  maintain  synchronization  in  planning  and  conduct  of 
operations. 

The  operational  model  does  not  directly  indicate  there  is  an  architecture  inherent 
in  the  way  the  organization  behaves.  Architecture  implies  patterns,  but  the  patterns  may 
not  be  evident  in  the  model.  Once  the  operational  model  is  constructed,  it  may  be 
possible  to  identify  operational  patterns. 

In  this  COP  21  Conceptual  Operational  Architecture  project,  the  operational 
architecture  revealed  by  the  examination  of  the  operational  model  expresses  three  nested 
operational  loops  (OODA)  with  a  common  core  service,  Provide  Situation  Awareness. 
The  diagram  [Figure  13  ]  illustrates  the  operational  architecture  revealed  by  the 
operational  model.  Examination  of  the  operational  model  reveals  the  extent  to  which  the 
doctrine  and  SOPs  support  a  conceptual  operational  architecture.  The  process  of 
examination  may  yield  good  insight  to  possible  conflicts  in  the  doctrine  that  inhibit  the 
desired  consistent  operational  behavior. 
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GOC  Tasking 


Figure  13:  Operational  Architecture 

The  way  ahead  -  from  network-centric  to  architecture-centric 

If  the  command  system  is  viewed  as  an  infrastructure  of  network  services  (as  in 
“network  centric  warfare”),  then  the  operational  architecture  is  an  essential  element  in 
identifying  core  and  common  services  that  support  multiple  organizational  units  and 
utilize  common  and  consistent  data.  The  operational  architecture  is  a  product  of  the 
operational  model  and  should  be  the  basis  for  evaluating  or  modifying  doctrine,  for 
identifying  and  specifying  new  operational  capabilities,  and  for  managing  the  evolution 
of  the  command  system.  The  network  should  be  transparent  and  the  future  should  be 
seen  as  “architecture -centric  warfare.”  Operational  modeling  and  operational 
architectures  point  the  way  forward,  lighting  the  way  for  managing  the  complexities  of 
open,  distributed  command  systems  in  the  21st  century. 
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